home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 882 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.4 KB
  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: clamage@Eng.sun.com (Steve Clamage)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: delete vs incomplete class type
  5. Date: 27 Mar 1996 21:49:38 GMT
  6. Organization: Sun Microsystems Inc.
  7. Approved: clamage@eng.sun.com (comp.std.c++)
  8. Message-ID: <4jccdg$78i@engnews1.Eng.Sun.COM>
  9. References: <sjcDownA7.6FA@netcom.com>
  10. Reply-To: clamage@Eng.sun.com
  11. NNTP-Posting-Host: taumet.eng.sun.com
  12. X-Nntp-Posting-Host: taumet.eng.sun.com
  13. Content-Length: 2534
  14. X-Lines: 59
  15. Originator: clamage@taumet
  16.  
  17. In article 6FA@netcom.com, sjc@netcom.com (Steven Correll) writes:
  18.  
  19. >What must a conforming compiler do when confronted with this?
  20. > 
  21. >        struct x;
  22. >        struct y;
  23. > 
  24. >        void
  25. >        p(x *arg0, y *arg1)
  26. >          {
  27. >          delete [] arg0;
  28. >          delete arg1;
  29. >          }
  30.  
  31. >Section 5.3.5 of my 5/95 copy of the draft standard says "If the object
  32. >being deleted has incomplete class type at the point of deletion and the
  33. >class has a non-trivial destructor...the behavior is undefined." Is this
  34. >still true?
  35.  
  36. Yes.
  37.  
  38. >I don't see how a compiler could avoid noticing that it hasn't a clue what
  39. >destructor to invoke at compilation time. Is there a reason (aside from
  40. >encouraging people to migrate to Java) not to require the compiler to
  41. >diagnose this as an error, instead of allowing it to fault at execution
  42. >time?
  43.  
  44. If x and y have trivial destructors, the code is well-formed. It would
  45. be possible to make the code unconditionally ill-formed, meaning that
  46. you could not delete an object unless its type is complete. I don't have
  47. a good answer for why this is not the case. (I only see two feasible
  48. definitions: status quo, or the code is always ill-formed.)
  49.  
  50. I would expect a compiler to warn about deleting incomplete types.
  51. The current Sun C++ does, for example.
  52.  
  53. I don't understand the reference to Java. In Java, all objects of class
  54. type are on the heap and are garbage-collected. This has the obvious
  55. advantage of eliminating memory-management errors. On the other hand,
  56. you cannot predict when (or whether, under current Java versions) an
  57. object will ever be destroyed, so doing anything important in a
  58. "destructor" (finalize) seems ill-advised. In effect, it seems to me
  59. that "destructors" in Java should always be trivial, and if cleanup
  60. actions are needed, they should usually be put in a method you call
  61. explicitly at the appropriate time.  Hmmm -- seems isomorphic to the
  62. C++ memory-management problem, except for having somewhat limited bad
  63. consequences. 
  64.  
  65. (OK, the comparison might not be completely fair. Typically, a C++
  66. destructor is needed to free allocated memory, and Java never needs a
  67. destructor for that purpose. But if the destructor is needed to free
  68. some other resource -- close a file, release a lock -- you are back
  69. to the "when does it happen" problem. Future versions of Java are
  70. supposed to guarantee that the "finalize" method of every object is
  71. eventually run, but you cannot predict or control the order in which
  72. they are run.)
  73.  
  74. ---
  75. Steve Clamage, stephen.clamage@eng.sun.com
  76.  
  77.  
  78.  
  79.  
  80. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  81. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  82. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  83. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  84. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  85.